Agile Development: What we can learn from property developers – or what they’ve learned from us

Howard Podeswa — Sun, 13 Dec 2009 05:01:00 GMT

Readers of this blog (both of you; I know you’re out there!) may have gathered by now that I’m a big fan of mixing it up: art/science/business/philosophy/politics/psychology and anything else that can be thrown into the pot. I believe that the more you let your worlds bleed into each other, the more opportunity there is to benefit from the cross-pollination of ideas.

I had a vivid example of this recently. I was having dinner with a friend of mine – who also happens to be a gifted architect and designer. We were talking about a project he is working on where he is responsible for handling design aspects of a large commercial property development. One of the things that struck him as particularly challenging on this project was the fact that the buildings were literally going up as the design was being worked on. This meant that many different activities were going on at the same time. Instead of going through a single pass of upfront design followed by construction, they were developing this project in a set of short cycles; each time through they pinned down the requirements for an aspect or area of the complex, did just enough design to get it built and then constructed it on the ground.

Sound familiar? What he was describing was iterative-incremental development – an approach to managing software projects that is the basis of agile approaches, IBM’s RUP (Rational Unified Process) and Microsoft’s MSF.

It’s interesting to note that the classic (i.e. older) approach to managing software projects was based on the how the construction industry managed its projects at that time: a single cycle of requirements analysis, design, testing and construction, known in the IT world as the ‘waterfall’ approach. That got me wondering whether the influence is now flowing on the opposite direction. Are managers of construction projects now learning a trick or two from their counterparts in the IT world?

These are not rhetorical questions. I’m expecting an answer – or at least looking forward to your comments, and maybe even instigating a little cross-breeding for those of you who have friends in the design or construction industry. To wit: Does anybody out there know when iterative development began to take off in the construction industry? For those of you with friends in the design, construction, or property development sectors: Do you know of any examples of iterative construction projects and, if so, what are the challenges and lessons learned?

By the way, I asked these questions of my friend, the architect, in order to see if there were any ‘lessons learned’ that could be applied to the IT world. He told me that the biggest challenge for the design shop, was to avoid making a decision they would later come to regret. This was a real risk, because they were designing while some of the requirements were still unknown. It’s a challenge BAs on iterative projects should all be able to appreciate. Asked how they were mitigating this risk, he summarized their approach as follows:

Don’t commit to something today that you can put off till tomorrow. In other words, if you can delay a decision without delaying the project, put the decision off. But if you have to make a decision, then …

Choose the option that least constrains the future. That way you minimize the impact of making a wrong decision.

Here’s an example of how the second principle works in his industry: The designers were required to put in a staircase before they even knew how the rooms on that floor were going to be used and what their individual sizes and layout would need to be. So the designers chose a staircase position that left them with the most flexibility for laying out the rooms later. In this case it meant rejecting a central staircase, because it would rule out options for room layouts more than a staircase off to one side.

You can see how these lessons can be immediately applied to IT projects. As to which sector originated the idea of iterative development, one thing is certain: Wherever the iterative idea started, everyone who is doing it – regardless of the sector they’re in – has a lot to learn from each other. Let’s get the conversation started.

Howard Podeswa, author of UML for the IT Business Analyst

Agile - the way I like it...

Adrian M. — Mon, 11 May 2009 10:00:00 GMT

This month’s eJournal issue is about Agile and the Agile Business Analyst with a couple of great articles by Ellen Gottesdiener and Scott Ambler exposing upon the agile side of the business.

At ModernAnalyst.com we try really hard to showcase editorial content which is relevant, educational, well balanced, and thought provoking. For the most part, as an editor, I try to stay on the sidelines when it comes to controversial topics such as the Agile vs. Traditional methods.

Yet today I couldn’t resist chiming in! Ouch!

I tend to be a middle of the road guy and, in general, I try not to get stuck on any one of extremes – regardless of subject or topic. My belief is that if it works for me then I’ll continue to use it and I also strongly advice you that if it works for you then you should continue to use it – whatever it is.

But Jason Gorman puts it my better:

If it works, do it
If it works, it works
If it seems to work, it probably works
If it seems to work, it probably works – and might work again

He calls this The Post-Agile Manifesto (disregard the toilet – I haven’t figured that one yet). For more, here’s a Post-Agilism FAQ.

The idea is that fanaticism is not a good thing on either side of the fence. Some agilists when they hear of waterfall projects which succeed, claim the team must have used agile and gave the process a wrong title. Traditionalists who witness successful agile projects call them hacks destined for eventual failure.

As a business analyst, trying to make sense of it all, you might find yourself thinking “agile is bad” because there doesn’t seem to be a well defined role for the BA on an agile team or, perhaps, you’ve started your career as an agile BA and cannot comprehend while anybody in their right mind would want to write a 100 page requirements document.

Unfortunately, the debate between agile and traditional software development processes is alive and well with both side of the camp continuing to fire salvoes at each other.

The truth, as I see it, is probably somewhere in between - as I’m sure you’ll find examples of success stories where:

Agile methods were used to develop large-scale applications,
Traditional methods were employed on small projects,
Agile teams utilized use case narratives,
Traditional teams created user stories to document requirements,
Etc.

The reality is somewhere in between the Traditional Methods and the Agile Manifesto with:

many traditional processes such as the Rational Unified Process (RUP) incorporating agile iterations and other agile concepts, and

agilists turning to more structure and formal processes as witnessed in the Enterprise Unified Process (EUP).

Since this month’s eJournal issue is on Agile – let’s get back there!

Is Agile bad?

No.

However, the type of agile movement that I like is the one that realizes that “agile” is not the end goal.

Creating value is a good goal.

Solving business problems is where it’s at.

Getting the job done is what’s important.

If it works, use it – whatever it is!

Do not be afraid to use what works, don’t shy away from learning something new, and keep on improving our profession and craft regardless what the end process/methodology may be called.

- Adrian

Adrian Marchis

Publisher, ModernAnalyst.com

PS: Are you scared of Agile?

Disgusted with Traditional methods?

What’s on your mind?

I’d love to know!

Business Analyst Community & Resources | Modern Analyst

Agile Development: What we can learn from property developers – or what they’ve learned from us

Agile - the way I like it...